Internet Info 1993

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / networking / terms / kermit / b / ckvins.doc < prev next >

Wrap

Text File | 1993-08-12 | 28.9 KB | 723 lines

C-KERMIT 5A INSTALLATION INSTRUCTIONS FOR VMS and OpenVMS -*-text-*- 5A(189) Most Recent Update: Thu Aug 12 13:57:17 1993 F. da Cruz, C. Gianone, Columbia University, New York, NY Terry Kennedy, Saint Peters College, Jersey City, NJ And: Peter Mossel, James Sturdevant Copyright (C) 1985, 1993, Trustees of Columbia University in the City of New York. The C-Kermit software may be reproduced and shared without restriction as long as this copyright notice is retained, except that it may not be licensed or sold for profit as a software product itself, and it may not be included in or distributed with commercial products or otherwise distributed by commercial concerns to their clients or customers without written permission of the Office of Kermit Development and Distribution, Columbia University. DISCLAIMER: The C-Kermit software is provided in source code form by Kermit Development and Distribution, Columbia University. The software is provided "as is;" no other warranty is provided, express or implied, including without limitations, any implied warranty of merchantability or implied warranty of fitness for a particular purpose. "VMS" as used in this document refers to both VMS and OpenVMS on VAX processors and OpenVMS on Alpha AXP processors. Most of the words in the previous sentence are trademarks (TM) of Digital Equipment Corporation. Neither Columbia University nor any of the contributors to the C-Kermit development effort, including, but not limited to, AT&T, Digital Equipment Corporation, Data General Corporation, International Business Machines Corporation, or Saint Peters College warrant C-Kermit software or documentation in any way. In addition, neither the authors of any Kermit programs, publications or documentation, nor Columbia University nor any contributing institutions or individuals acknowledge any liability resulting from program or documentation errors. DOCUMENTATION C-Kermit 5A is documented in the book "Using C-Kermit" by Frank da Cruz and Christine M. Gianone, Digital Press, Burlington, MA, USA. Digital Press ISBN: 1-55558-108-0; Prentice-Hall ISBN: 0-13-037490-3. Price: US $34.95. In USA, call DECdirect at 1-800-344-4825, refer to order number EY-J896E-DP. CONFIGURING VMS FOR BEST RESULTS WITH KERMIT 1. TERMINAL BUFFER SIZE VMS is shipped with default installation parameters designed to function on all possible configurations. Some of these parameters have not been changed since the "average" VMS system was a VAX-11/780 with 1Mb of memory. The main parameter that affects Kermit is the terminal type-ahead buffer size, which applies to serial terminal devices (with the TT or TX prefix). There are two possible values in VMS - the "normal" size and the "alternate" size. The defaults for these are 78 and 200 bytes, respectively. If more data arrives at the terminal driver than these buffers can hold (which is a likely occurrence during file transfer), it will be discarded and file transfers will be slowed down or terminated by errors. This is most frequently seen when receiving files on a slow VAX, particularly when using long packets and/or sliding windows. File reception requires larger system buffers (to hold arriving packets), and the speed of the VAX controls how quickly Kermit can empty them. The recommended minimum size for each of these buffers is the number shown as "Buffer size" by the C-Kermit SHOW PROTOCOL command, which is the total amount of memory allocated by C-Kermit for packet buffers (window slots times packet length). VMS C-Kermit is shipped with a buffer size of 9065, which can be altered by the user with a SET BUFFERS command. To change the values of the VMS typeahead buffer sizes, you should edit the file SYS$SYSTEM:MODPARAMS.DAT. Determine the new values you want to use and add lines like the following to the end of the MODPARAMS.DAT file: MIN_TTY_TYPAHDSZ = new_value_for_regular ! For VMS C-Kermit MIN_TTY_ALTYPAHD = new_value_for_alternate ! For VMS C-Kermit for example: MIN_TTY_TYPAHDSZ = 2064 MIN_TTY_ALTYPAHD = 2064 The TTY_ALTYPAHD size should be at least as great as the TTY_TYPAHDSZ. Digital recommends a value of 2064 or greater for TTY_ALTYPAHD if you are running VMS V5.5 or higher, or if you are running the optional LATmaster code under VMS V5.4-1, -2, or -3. You should also examine this file to be sure there aren't any other definitions for TTY_TYPAHDSZ or TTY_ALTYPAHD. If there are, you'll get warning messages in the next step. You may wish to simply set TTY_TYPAHDSZ=TTY_ALTYPAHD=2064, since most common VMS "TTY ports" these days are actually LAT or TCP/IP devices, which cannot easily be configured to use the alternate buffer. Also, it takes a privileged user or program to set a port to use the alternate buffer, and since we do not recommend installing Kermit with privileges, this would restrict Kermit access to privileged users. Let's consider a medium-sized VAX with perhaps 64 "ports" (either serial ports or LAT or TCP/IP network ports). This system probably has at least 16 megabytes of memory. Configuring TTY_TYPAHDSZ to 2064 will take up 64 * 2064 bytes of memory, or 132096 bytes. This is less than 1 per cent of available memory. Most systems would have more than 16Mb of memory for 64 simultaneous users, lowering the percentage even further. In some cases, it might also be necessary to increase your system's MAXBUF parameter. It should be somewhat longer than the longest packet you want Kermit to be able to send or receive, to allow for SYS$QIO overhead (the bigger the value, the more overhead). DEC currently recommends 2300, which should be sufficient for 2K (2048-byte) packets. If you want to use C-Kermit's maximum packet length, 9024, then your MAXBUF should be set to about 12000. To have these changes take effect, run the "AUTOGEN" procedure: @SYS$UPDATE:AUTOGEN GETDATA SETPARAMS This incorporates the new buffer sizes into the system configuration, and they will take effect the next time the system is reloaded. To examine your system parameters: run sys$system:sysgen SYSGEN> use current SYSGEN> show maxbuf (should be at least 2064) SYSGEN> show virtualpagecnt (should be at least 50000) SYSGEN> show /tty (TTY_ALTYPAHD should be at least 2064) In an emergency, or for testing purposes, you can also change your MIN_MAXBUF value "on the fly": $ run sys$system:sysgen SYSGEN> set maxbuf 2300 SYSGEN> write current SYSGEN> exit This operation should be used with caution, and should probably NOT be used with values greater than about 3000. The AUTOGEN procedure is safer because it understands the relationships among the major parameters. 2. USER QUOTAS AND PRIVILEGES C-Kermit communications are also affected by the user's BYTLM quota and possibly also the process page quota (PGFLQUO). In modern versions of VMS, the default BYTLM quota is 8192, which should normally be adequate. If C-Kermit users experience error messages informing them that a quota was exceeded during terminal emulation or file transfer, the system manager should increase the user's BYTLM and/or process page quota. To find out the user's quotas, the system manager should: set default sys$system run authorize UAF> show <username> Then look for the relevant quotas and adjust them as required. The BYTLM quota should be somewhat greater than the product of Kermit's window size and packet size, for example, 8192 for 4 window slots and 2000-byte-packets. PGFLQUO should be 20,000 or higher. If users will be using C-Kermit's PUSH command or issuing REMOTE commands (such as REMOTE DIR) to the VMS C-Kermit server, the user will need to have the ability to create subprocesses (AUTHORIZE parameter PRCLM). If Kermit will itself be invoked as a subprocess (for example, from within a menu system) this should be considered as well. Kermit uses local mailboxes for remote command execution, so users will also need the TMPMBX privilege if these commands are to be used. 3. CONFIGURING SERIAL COMMUNICATION PORTS If your system has a port that is frequently used for file transfers (for example, with a modem), you should have your system manager enable the alternate type-ahead buffer by placing the command: $ SET TERMINAL ddcu:/PERMANENT/ALTYPEAHD in the system-wide startup command file, where ddcu: is the name of the device, for each such device. If the device is connected to a modem, and is to be used for dialing out, also include the /MODEM qualifier: $ SET TERMINAL ddcu:/PERMANENT/ALTYPEAHD/MODEM If it is not connected to a modem or other data communications device that follows the RS-232 signalling conventions, you might have to set the /NOMODEM qualifier instead: $ SET TERMINAL ddcu:/PERMANENT/ALTYPEAHD/NOMODEM Additionally, for non-privileged users to access a terminal device, they need to be granted access to it. The default for terminals is access only by users with SYSTEM privileges (UIC group less than or equal to MAXSYSGROUP, or with SYSPRV privilege). See the VMS documentation for the SET PROTECTION command for more information. Note that if you grant everyone access to the port, anyone can make phone calls via the modem, so you might want to limit this to particular users, possibly by using a device ACL (VMS V5.0 and later only). 4. LAT DEVICES LAT ports present additional complications. Most LAT problems are not in Kermit, but can be reproduced using the SET HOST/DTE command or the SET HOST /LAT command. The VMS LAT documentation contains information on configuring LAT ports and troubleshooting problems. Your terminal server might have come with additional documentation. Experience shows that it is difficult to properly configure a LAT port to handle both incoming and outgoing connections. Therefore seperate LAT ports are recommended for incoming and outbound connections. 5. CAPTIVE ACCOUNTS Some VMS sites restrict users from getting at the DCL prompt and services by setting their accounts to be "captive". This should automatically prevent C-Kermit's DCL-access commands (such as PUSH) from working. Any attempt to execute such a command should result in C-Kermit issuing an error message. Should a user circumvent this, VMS will automatically terminate the user's process. In addition to CAPTIVE, accounts can also be set to RESTRICTED, to disable all types of spawning. Note that DEC says that RESTRICTED is only used "to ensure users complete login processing without interruption". DEC further states that they intend to modify VMS utilities to no longer prohibit spawning in a future release. Further, you should be aware that preventing users from getting to DCL only provides an illusion of security. There are many ways of getting to DCL which are non-obvious. For cases where absolute security is required, you should in- vestigate the AUTHORIZE flags CAPTIVE and DISIMAGE. Consult the VMS Security Manual for more information. C-Kermit itself can be configured to prevent system access, by compiling it with the NOPUSH option, for example: $ localopts = "/define=(""NOPUSH"")" $ @ckvker.com This disables not only the PUSH command and its synonyms (RUN, @, SPAWN), but also OPEN !READ, OPEN !WRITE, as well as the server's execution of REMOTE HOST commands. See CKCCFG.DOC for further information. DECODING VMS C-KERMIT HEX FILES If you have obtained the executable VMS C-Kermit program encoded in printable "hex" format on magnetic tape or over a network, you can decode it back into a runnable .EXE program image using the CKVDEH.MAR program. This is an assembly-language program for the VAX or Alpha AXP, which you should assemble, link, and run as follows: $ macro ckvdeh (on the Alpha AXP, substitute "macro/migrate ckvdeh") $ link ckvdeh $ run ckvdeh CKVDEH prompts you for the input and output file names. This procedure works on both the VAX and the Alpha AXP -- the same program, CKVDEH.MAR, compiles and runs on both platforms. The C-Kermit .EXE files were built under VAX/(Open)VMS 5.x and Alpha AXP OpenVMS 1.x. The VAX versions will not run under pre-5.0 VAX/VMS releases. Since VMS C-Kermit can be built with no TCP/IP support or with support for several different TCP/IP packages, and it can be built on both the VAX and Alpha AXP platforms, you should pick the right .HEX file for your environment: TCP/IP Product VAX Alpha AXP none CKVKER.HEX CKVAXP.HEX DEC TCP/IP (UCX) CKVVUCX.HEX CKVAUCX.HEX TGV MultiNet CKVVTGV.HEX *CKVATGV.HEX Wollongong WIN/TCP (PathWay) CKVVWIN.HEX *CKVAWIN.HEX Process Software TCPware *CKVVPST.HEX *CKVAPST.HEX Labeled file converter: CKVCVT.HEX CKVACVT.HEX (*At this writing, these hex files are not yet available.) NOTE: The TGV MultiNet version can be compiled and linked successfully on the Alpha AXP, but it cannot make TCP/IP connections succesfully. However, the Alpha AXP UCX version also works with MultiNet on the Alpha AXP. BUILDING VMS C-KERMIT FROM THE SOURCE CODE C-Kermit is written in the C programming language. To build C-Kermit on the VAX, you must have VAX C 3.0 or later, or GNU GCC. VAX C has undergone a large number of changes during its lifetime. Some header files may be missing in earlier versions. VMS C-Kermit was developed using VAX C V3.2 and VMS V5.5, but it was designed to work on earlier systems, back to VMS 4.4 and VMS C 3.0, if built in those environments (testing is needed for verification). Please report any problems building C-Kermit on older VMS/C configurations they can be fixed (or at least documented as problems). The User Authorization File (UAF) parameters of the account in which C-Kermit will be built must be set to accomodate the large size of some source modules. Recommended values are: PAGE FILE QUOTA: at least 60000 Working set extent: at least 5012 To modify: Suppose a user KERMIT is the VMS account from which Kermit is maintained. To set these values, the system manager must do the following: $ set default sys$system $ mcr authorize UAF> modify kermit/pgflquo=60000/wsextent=5012 UAF> exit If errors such as: %cc-f-text Virtual Memory limits exceeded occur during the build procedure, these parameters may need adjustment (upwards). To build C-Kermit, create a new directory and make it your current directory: $ CREATE/DIR [.KERMIT] $ SET DEFAULT [.KERMIT] and put the C-Kermit source files and build procedures there, for example by copying them from the distribution tape or cartridge. Two build procedures are provided. You can use either one: 1. For those with VMS MAKE (available from DECUS, written by Todd Aven of the Software Sweatshop in Long Beach, NY, and also distributed with VMS C-Kermit on magnetic tape or cartridge by Columbia University; to install it, follow the directions in CKVMAK.HLP), a makefile is supplied, called CKVKER.MAK, originally written by Terry Kennedy of Saint Peters Collge, Jersey City, New Jersey. The makefile is CKVKER.MAK. Rename it to MAKEFILE. (note the period): $ RENAME CKVKER.COM MAKEFILE. To build C-Kermit with DEC C, type (but don't do it yet -- first read about network options below): $ MAKE at the DCL prompt (shown as $). To build C-Kermit with GNU C, type: $ MAKE GKERMIT Use MAKE if you plan to be editing the source files and rebuilding C-Kermit periodically. This eliminates the need to recompile source files that have not been changed. 2. The CKVKER.COM DCL command procedure. This procedure unconditionally compiles and links all the source modules into WERMIT.EXE. This procedure can be used on any VAX that has suitable versions of VMS and C, and it is the procedure you would normally use if you do not intend to be modifying the source code after building the program. To build C-Kermit with the DCL procedure, type: $ @CKVKER NOTE: CKVKER.COM should not be edited except for strictly local purposes. It is generated automatically from CKVKER.MAK by: $ MAKE/KEEP/NOEXECUTE/FORCE/OUT=CKVKER.COM All changes of a global nature should be made to the makefile and then a new CKVKER.COM generated from it as shown. ANOTHER NOTE: As of this writing, CKVKER.COM must be used on Alpha AXP systems since the VMS MAKE program has not yet been adapted to the AXP. If you have the DEC FORTRAN 6.0 library, UVMTHRTL.EXE, installed, the resulting KERMIT.EXE file will not run on VMS systems that have an older FORTRAN library, or lack one altogether: %DCL-W-ACTIMAGE, error activating image MTHRTL -CLI-E-IMGNAME, image file $1$DIA0:[SYS1.SYSCOMMON.][SYSLIB]UVMTHRTL.EXE -SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image The new FORTRAN library has a different identifier. To link with the old version of the FORTRAN, two possibilities exist: 1) Link with SYS$LIBRARY:STARLET/LIB which uses NO shareable images. 2) Perform two defines prior to linking (this causes warning messages) DEFINE/USER MTHRTL FORTRAN$MTHRTL-VMS DEFINE/USER VMTHRTL FORTRAN$VMTHRTL-VMS The second option has been tested successfully on a VAX/VMS system that has neither FORTRAN nor C installed. CUSTOMIZING THE BUILD PROCEDURE If you have a DCL symbol "localopts" (case doesn't matter) defined when you use either the makefile or the .COM file, the contents of that symbol will be added to the C compiler command line after the existing options. You can use any legal CC compiler option there. For example, if you want to override a siteopts definition, you can add: $ LOCALOPTS = "/UNDEFINE=(""DYNAMIC"")" $ MAKE -- or -- $ @CKVKER Note the doubled quotes because they're inside a symbol definition. If you don't have a LOCALOPTS symbol, the null string is used. LOCALOPTS is evaluated in the generated .COM file, so it works for both the makefile and the .COM file. Read CKCCFG.DOC for further information about compile-time options for feature selection. VMS TCP/IP NETWORKING SUPPORT FOR C-KERMIT VMS C-Kermit is capable of establishing TCP/IP TELNET connections and acting as a TELNET program with built-in file transfer, script programming, character-set translation, etc, if it is built appropriately. If you have one of the following products installed on your system, complete with libraries and header files: 1. DEC TCP/IP (UCX) 2. TGV MultiNet TCP/IP 3. Wollongong WIN/TCP 4. Wollongong PathWay 5. Process Software TCPware then you can include TCP/IP capability in your version of VMS C-Kermit. The TCP/IP product is selected automatically by the build procedure based on the presence or absence of certain files on your system. To override the automatic selection, define the symbol NET_OPTION in one of the following ways before running the build procedure: $ NET_OPTION = "NONET" ! Build with no TCP/IP networking support $ NET_OPTION = "DEC_TCPIP" ! Build with DEC TCP/IP (UCX) support $ NET_OPTION = "MULTINET" ! Build with TGV MultiNet TCP/IP support $ NET_OPTION = "WINTCP" ! Build with WIN/TCP or PathWay support $ NET_OPTION = "TCPWARE" ! Build with Process Software TCPware support That is, type one of the commands listed above at the DCL prompt (shown above as "$") before running the build procedure. DEC TCP/IP (UCX) If the DEC TCP/IP version of KERMIT.EXE crashes immediately upon startup with a message like: %LIB-E-ACTIMAGE, error activating image R4GRIE$DIA0:[SYS0.SYSCOMMON.][SYSLIB]UCX$IPC_SHR.EXE;1 -SYSTEM-F-PRIVINSTALL it means the system manager has to install the UCX sharable library: INSTALL ADD SYS$SHARE:UCX$IPC_SHR.EXE WOLLONGONG TCP/IP Wollongong support should work for both new (PathWay) and older (WIN/TCP) versions, and C-Kermit versions linked under older Wollongong versions should still run under the newer version. But note that the pieces of the Wollongong package are now unbundled -- you have to buy the runtime, access, API, etc, pieces separately, and (of course) you need the API to compile C-Kermit with Wollongong TCP/IP support. If you are building with Wollongong TCP/IP, and you have the TCP/IP libraries and header files, but the #include files can't be found, then you need to unpack the WIN/TCP include-file library into separate files using the VMS LIBRARY command. TGV MULTINET If your VAX has the TGV MultiNet TCP/IP networking product, both procedures automatically build C-Kermit with MultiNet TCP/IP support included. However: . In older (pre-V3.1) MultiNet installations, the header files might not be installed. Without these, C-Kermit will not build correctly. The system manager can add Multinet 3.1 programming support by installing MNETLIB031 from the Multinet distribution, if licensed to do so. . Anyone building the VMS version with certain versions of TGV MultiNet support under VAX C 3.1 might get an error message about conficting definitions of "time_t". This is because of a conflict between DEC's <types.h> and MultiNet's <types.h> caused because DEC changed the definition between VAX C 3.0 and 3.1. Kermit can't do anything about this because CKVTIO.C #includes <time.h>, which itself includes <types.h>. The warning is not fatal. INSTALLING VMS C-KERMIT Until (and unless) the VMSINSTAL kits are ready (see below), VMS C-Kermit must be installed on your VMS system by hand. (NOTE: It is not yet certain that there ever will be VMSINSTAL kits, since they would have to include many megabytes of differently-configured executables to choose from, plus the fact that many of system-configuration items discussed above are best done by the system manager manually, in privileged mode, after some thought and consideration). IMPORTANT: DO NOT INSTALL VMS C-KERMIT AS A PRIVILEGED PROGRAM! Instead, install it as a foreign command. To install C-Kermit, follow this procedure: 1. If you have the old Bliss Kermit-32 on your system, rename it to KERMIT32. If you have a symbol KERMIT defined to run Kermit-32, change the symbol name to KERMIT32. 2. Identify the directory where you want to install the C-Kermit program. Normally this would be a directory that is unaffected by installation of DEC software, such as SYS$TOOLS = SYS$SYSDEVICE[SYSTOOLS]. From now on, we will assume you are using SYS$TOOLS:. 3. Copy WERMIT.EXE to that directory, rename it to KERMIT.EXE, and give users permission to run it, for example: $ COPY WERMIT.EXE SYS$TOOLS:KERMIT.EXE $ SET PROTECTION (S:RWED,O:RWED,G:RE,W:RE) SYS$TOOLS:KERMIT.EXE 3. Copy the standard CKERMIT.INI file to the same directory: $ COPY CKERMIT.INI SYS$TOOLS: $ SET PROTECTION (S:RWED,O:RWED,G:RE,W:RE) SYS$TOOLS:CKERMIT.INI 4. Add the following line to SYS$COMMON:[SYSMGR]SYSTARTUP_V5.COM (or whatever your system startup file is): $ DEFINE/SYSTEM CKERMIT_INI SYS$TOOLS:CKERMIT.INI 5. Find your system-wide login DCL command procedure: $ SHOW LOGICAL SYS$SYLOGIN "SYS$SYLOGIN" = "SYS$TOOLS:SYLOGIN.COM" (LNM$SYSTEM_TABLE) and then add the following line to it: $ KERMIT :== $SYS$TOOLS:KERMIT 6. Install the C-Kermit HELP file in your VMS HELP library. First delete any earlier KERMIT help entry, then install the new one: $ LIBRARY/HELP/DELETE=KERMIT SYS$HELP:HELPLIB.HLB $ LIBRARY/INSERT/HELP SYS$HELP:HELPLIB.HLB CKVKER.HLP 7. Create a publicly accessible directory, such as [KERMIT], in which to make other C-Kermit files available to your users: CKERMIT.KDD Sample dialing directory file. CKERMIT.KSD Sample services directory. CKEDEMO.INI Macro definitions from "Using C-Kermit". CKEVT.INI Command file to demonstrate special screen effects from "Using C-Kermit". CKCKER.UPD A supplement to the book, "Using C-Kermit", describing features added since the book was published. CKCKER.BWR The general C-Kermit beware file. CKVKER.BWR The VMS-specific C-Kermit beware file. CASE STUDY: ALPHA AXP SETUP AND TEST RESULTS (by Peter Mossel) Model number: DEC3000/400, a workstation with 64MB of memory. Ports used: OPA1: (a MMJ connector for the alternate operator console) TTA1: (a 25-pin male D-connector on the back) Operating System: OpenVMS AXP V1.0 Firmware: V1.1 Upon power-up, the console displays something like: ... CPU OK KN15-BA V1.1-S11A IO20 sV1.0 DECchip 21064 P2.1 ... Testing setup 1: OPA1: +-------+ | MMJ--- DECconnect cable ---MMJ H8571-A--- modem cable to PC +-------+ (passive adapter) In words, plug a DECconnect cable with MMJ plugs on both ends in the alternate console port on the back of the DEC3000/400. Make sure S3 is in the "up" position. The workstation screen is now the console (OPA0:) and the extra port, OPA1:, is available for connecting a terminal or printer. This MMJ plug is the only MMJ plug on the back of this machine. My other host for the test is a DECpc 466, a 66MHz i486 with DOS 5.0 and MS-DOS Kermit 3.12. The 466 has 2 serial ports, both 9-pin. I attached a standard 9-pin to 25-pin modem cable (the ones that came into existence with the IBM PC/AT which originally had only a 9-pin serial port) to the serial port on the 466. Now we must join a 25-pin connector and a MMJ connector. This is done with a passive adapter (H8571-A) which converts the RS423 signalling standard (balanced TX+ TX- RX+ RX-, DTR, DSR) to RS-232. All this is fairly standard for DEC sites. Note that when connecting a modem to an MMJ connector, we have only a subset of the required modem signals, so this is not supported via MMJ. The other port (TTA1) has full modem control. Note that the DECconnect cable always reverses TX and RX, so it effectively functions as a NULL-modem cable. Testing setup 2: TTA1 +-------+ | 25-pin D connector --- NULL modem cable to PC +-------+ Use the (only) 25-pin D-connector on the back. Now we need a null modem cable (see the Kermit book), and, because my PC has a 9-pin serial port, I also need a 9-pin to 25-pin modem cable. Testing setup 3: LAT Connect the PC with a standard cable to the terminal server, which speaks LAT to my DEC3000/400. The speed can be set up to 19200 baud with the terminal server in use. Test script for setup 1 and 2: On DEC3000: $ kermit C-Kermit>set line xxx (where xxx is OPA1 or TTA1) C-Kermit>set speed 19200 On the PC C:\kermit MS-Kermit>set port 1 MS-Kermit>set speed 19200 MS-Kermit>server On the DEC3000: C-Kermit>get test.fil C-Kermit>finish On the PC MS-Kermit>quit Test script for setup 3 (LAT): On the PC C:\kermit MS-Kermit>set port 1 MS-Kermit>set speed 19200 MS-Kermit>connect [ Now log into DEC3000 as host ] $ kermit -x [ back to the PC ] MS-Kermit>get test.fil MS-Kermit>bye Results: In all three cases, the data transfer speed is excellent. Over 80% of the bandwidth of the communication channel is used for the file transfer, sometimes even more. The DEC3000 is loaded with processes (MOTIF, Sybase DBMS, NFS clients and servers,...) and heavy network activity (DECnet, LAT, TCP/IP but no characters have ever been lost, even when the DBMS fires up. No special SYSGEN parameters, just configured for a normal workstation with MOTIF. Notes: 1. Device protection In a system like this out of the box, the device protection on TTA1 and OPA1 does not allow an unprivileged user to use these lines for DIAL-OUT from Kermit. Thus, the system manager must set every time the system is rebooted: $ set protection=w:rwlp/device OPA1: $ set protection=w:rwlp/device TTA1: Without these special protections, a terminal connected to these ports will still be able to login and get the "Username:" prompt. 2. Console device speed The VMS AXP V1.0 cover letter mentions that the command $ set terminal/speed=nnnn/perm/opa1: will have no effect on the speed of OPA1. In practice, there is no problem with Kermit file transfers. The data just get thru fine and file transfers are OK. But Kermit gets confused when it calculates line thruput based on 300 bps. The release notes also mention that setting the speed of OPA1 can be accomplished by setting the console environment variable "tta1_baud" to the desired speed. See the hardware guide on how to do this. The problem will be fixed in a future release. MAKING AND USING VMSINSTAL KITS (NOTE: This section is only for future reference, in case it becomes practical to build VMSINSTAL kits for C-Kermit. For now, please ignore.) After building C-Kermit using one of the procedures outlined above, execute the DCL procedure CKVMSI.COM to create a VMSINSTAL kit. This kit can be created either with or without the source code. In any case, it includes the C-Kermit executable program, the C-Kermit help file (for installation in your HELP library), plus a sample CKERMIT.INI (C-Kermit initialization) file, and release notes. You may now install C-Kermit using the command: @sys$update:vmsinstal kermit It will prompt you for which components you want installed, and where to put them. CKVMSI and CKVKIT were written by Terry Kennedy of Saint Peters College. (End of file CKVINS.DOC)